EC2インスタンスの基本モニタリングでもデータポイントは1分間隔で送信されている件

基本モニタリングの場合は、データポイントは5分に1回しか送信されないのか

こんにちは、のんピ(@non____97)です。

皆さんはEC2インスタンスの基本モニタリング(標準モニタリング)の場合、CloudWatchのデータポイントは5分に1回しか送信されないのか気になったことはありますか? 私はあります。

AWS公式ドキュメントには以下のようにデフォルト = 基本モニタリングでは5分ごとにデータポイントを送信するような記載がありました。

デフォルトでは、Amazon EC2 は 5 分ごとにメトリクスデータを CloudWatch に送信します。1 分ごとにインスタンスのメトリクスデータを CloudWatch に送信するには、インスタンスで詳細モニタリングを有効にできます。詳細については、「インスタンスの詳細モニタリングを有効または無効にする」を参照してください。

CloudWatch を使用したインスタンスのモニタリング - Amazon Elastic Compute Cloud

その一方で、基本モニタリングでは5分間のデータポイントが対象になると記載がありました。

Amazon EC2 はメトリクスを Amazon CloudWatch に送信します。AWS Management Console、AWS CLI、または API を使用して、Amazon EC2 が CloudWatch に送信するメトリクスを一覧表示できます。デフォルトで、各データポイントではインスタンスのアクティビティの開始後 5 分間が対象となります。詳細モニタリングを有効にした場合、各データポイントは開始後 1 分間のアクティビティを対象とします。注意事項[最小]、[最大]、[平均] の統計では、EC2 が提供するメトリックスの最小粒度は 1 分であることに注意します。

インスタンスの利用可能な CloudWatch メトリクスのリスト表示 - Amazon Elastic Compute Cloud

どちらが正しいのでしょうか。気になってみたので確認してみました。

いきなりまとめ

• 基本モニタリングでも内部的には1分間隔でデータポイントが送信されている
• 詳細モニタリングを有効にしている期間のデータポイントのみ、1分間隔で表示することができる

やってみた

基本モニタリングの場合

Amazon Linux 2023で試します。

まず、基本モニタリングの場合を確認します。

EC2インスタンスを起動開始して終了するまでのCPU使用率を確認しました。統計は平均で、期間は5分です。

次に期間を1分に変更します。

期間が5分の時と比べて何も変わりありませんね。

それでは統計を最大に変更します。

すると、02:15時の値が4.93%から19.1%に変わっていました。5分に一回しかデータポイントを送信しないのであれば、期間が5分の場合は統計を平均にしても最大にしても変わらないはずです。

統計を期間中のデータポイント数を示すサンプル数に変更します。

02:20から02:35の期間はデータポイントが5つあることが分かります。このことから基本モニタリングの場合でも内部的には1分間隔でデータポイントが送信されていると言えます。

なお、02:15が4、02:40が3となっているのはEC2インスタンスの起動と停止のタイミングの影響です。起動は2:15:49で、停止は2:42:12に行いました。

データポイントが記録されるタイミングをもう少し探ってみましょう。

EC2インスタンスは起動させっぱなしです。現在の時刻は1:48です。01:45のデータポイントは4となっています。

現在の時刻は1:50です。01:45のデータポイントは変わらず4のままです。

現在の時刻は1:50です。01:45のデータポイントが5に変わりました。ということで1~5、6~10という形で丸められているようですね。

詳細モニタリングの有効化

詳細モニタリングが有効の場合も確認しましょう。

気になるのは「詳細モニタリングを有効化することで、基本モニタリング期間のデータポイントも1分間隔で表示できるようになるか」です。

CPU使用率が0%だと動きがなく、面白くないのでAmazon Linux 2023にstressをインストールしてCPUに負荷をかけてあげます。

$ sudo dnf install stress -y
Last metadata expiration check: 23:30:05 ago on Wed Feb 28 02:16:03 2024.

<h1>Dependencies resolved.</h1>

<h1> Package                                     Architecture                                Version                                                      Repository                                        Size</h1>

Installing:
 stress                                      x86_64                                      1.0.4-28.amzn2023.0.2                                        amazonlinux                                       37 k

<h1>Transaction Summary</h1>

Install  1 Package

Total download size: 37 k
Installed size: 78 k
Downloading Packages:

<h2 id="toc-stress-1-0-4-28-amzn2023-0-2-x86_64-rpm-458-kbs-37-kb-0000">stress-1.0.4-28.amzn2023.0.2.x86_64.rpm                                                                                                                                      458 kB/s |  37 kB     00:00</h2>

Total                                                                                                                                                                        249 kB/s |  37 kB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                                     1/1
  Installing       : stress-1.0.4-28.amzn2023.0.2.x86_64                                                                                                                                                 1/1
  Running scriptlet: stress-1.0.4-28.amzn2023.0.2.x86_64                                                                                                                                                 1/1
  Verifying        : stress-1.0.4-28.amzn2023.0.2.x86_64                                                                                                                                                 1/1

Installed:
  stress-1.0.4-28.amzn2023.0.2.x86_64

Complete!

$ stress -c 1
stress: info: [10718] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

しばらくすると、以下のようにCPU使用率が50%となりました。

• 統計が平均

• 統計が最大

この状態で詳細モニタリングを有効化します。

詳細モニタリングを有効化したのは1:53です。

CloudWatchメトリクスで統計を最大で、期間を1分で確認します。

現在の時刻は1:55です。1分単位では表示されていません。

現在の時刻は1:58です。まだ1分単位では表示されていません。

現在の時刻は2:01です。1分単位で表示されるようになりました。基本モニタリング期間中の値は5分間隔で表示されています。

「詳細モニタリングを有効化することで、基本モニタリング期間のデータポイントも1分間隔で表示できるようになるか」という疑問については「変わらず最小は5分間隔」という答えになります。

CPUにさらに負荷をかけてみました。1分単位で値を確認できていますね。

サンプル数も確認してみましょう。

詳細モニタリング有効化後のデータポイントは1分単位で1回送信されていることが分かります。詳細モニタリング有効化前は変わらず5分単位でまとめられたものが表示されています。

詳細モニタリングの無効化

詳細モニタリングの無効化をした際の挙動も確認してみましょう。詳細モニタリングを無効にしたのは2:19です。

CPU使用率を確認します。02:19の値が表示されず、02:20に値が表示されました。なお、詳細モニタリング有効期間中の値は変わらずに1分単位で表示されています。

サンプル数は以下のとおりです。飛地になっていますね。

基本モニタリングでも裏側では1分間隔でデータポイントが送信されている

EC2インスタンスの基本モニタリングでもデータポイントは1分間隔で送信されていることを確認しました。

このことから、詳細モニタリングは「詳細モニタリングを有効にしている期間のデータポイントのみ、1分間隔で表示することを許可する機能」と理解しました。

詳細モニタリングを有効化するタイミングとしては、「期間を1分に設定し、5分の中でどのような動きがあるのかを知りたい場面」と考えます。「5分の間どのようにメトリクスが変化があったのかは別に知らないくても良い」という場合は、無理に有効化しなくても良いと考えます。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!